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(54) Method and apparatus for sharing a time quantum 



(57) A method and apparatus for allowing a first 
thread (112) to "share" its remaining time quantum with 
a second thread (112) when the first thread is blocked. 
A thread (1 1 2) may be blocked, for example, if it is wait- 
ing for a resource such as a data file or a lock. A thread 
may also be blocked if it is waiting for an event, such as 
a user keystroke. If there is a thread on the run queue 
that "owns” the resource needed by the consumer 
thread, the blocked consumer thread transfers its right 
to execute for a remaining time quantum to the owner 
thread, and the owner thread executes next. If the 
threads (1 12) are in a same process (110), this transfer 
means that no process context switch is required, since 
the consumer thread and the owner thread are threads 
of the same process (110). In addition, this transfer 
means that the time before the resource becomes avail- 
able to the blocked consumer thread will be short. Sim- 
ilarly, if a consumer thread is blocked to await an event, 
such as a user keystroke, the blocked consumer 
thread's remaining time quantum are transferred to 
another thread in that is waiting on the run queue for its 
turn to execute. Again, if the threads (112) are in a same 
process (110), this transfer avoids having to perform a 
context switch between processes. 
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Description 

HELD OF THE INVENTION 

[0001] This application relates to operating systems s 
and, specifically, to a method and apparatus that allows 
thread of a process to share a remaining quantum of 
processor time allotted to it with other threads. 

BACKGROUND OF THE INVENTION io 

[0002] Most modern computer systems are multi-task- 
ing systems. That is. they allow more than one "job” or 
"process" to be active at a given time. Since there Is 
often only one processor in the system (or a number of is 
processors less than the number of jobs/processes), it 
becomes necessary for the jobs/processes to share the 
processor resources. In a shared processor system, a 
processor spends some time executing part of a first 
job/process before switching to execute part of another 20 
job/process. Thus, to a human user, it appears that 
more than one job/process is being executed at a given 
time. 

[0003] Some computer systems execute "multi- 
threaded" computer programs in which multiple 25 
"threads" of a process can be executing at the same 
time. Multi-threading adds an extra note of complexity to 
the operating system and to processor sharing. 

[0004] In at least one implementation of the Solaris 
operating system (available from Sun Microsystems. 30 
Inc.), a highest priority job will run for a period of time 
(called a "time quantum") and then its priority is redeter- 
mined. There are currently four different scheduling 
classes that define the priorities of the applications in a 
conventional Solaris system: Real Time (RT); System 35 
(SYS); Interactive (lA), and Timesharing (TS). If, after its 
execution, a job still has the highest priority in the sys- 
tem, it is allowed to run for another period of time (e.g., 
between 20 to 200 milliseconds), after which the priority 
is redetermined again. If it is no longer the highest prior- 40 
ity job in the system after the redetermination, then a job 
that has a higher priority gets to run. Unfortunately, if a 
job maintains a highest priority, other applications do 
not always get a chance to execute. 

[0005] Many conventional operating systems use 45 
time-sharing processor-scheduling strategies that 
schedule threads independently. In such a system, 
each thread is assigned a priority and a time quantum 
and is put on a run queue to wait for its turn to use the 
processor. When a processor is available, it picks the so 
thread with the highest priority from the run queue and 
executes it. The thread is allowed to use the processor 
for the duration of the time quantum. When the thread 
uses up its assigned quantum, the thread's priority is 
recalculated, a new time quantum is assigned and the ss 
thread is put back onto the run queue. The processor 
then picks the next highest priority thread from the run 
queue and begins to execute it again. 



[0006] During its execution on a processor, a thread 
often requires an event to occur or some data or 
resource to be available before the thread can continue 
its computation. An example of an event might be a key 
stroke from a user or availability of a record from a file. 
Similarly, a thread may have to wait for availability of 
data, such as access to a lock that is shared with 
another thread. A thread that needs a resource is called 
a "consumer thread." When the resource or data is not 
available or when the event has not occurred, and the 
consumer thread needs to wait, the consumer thread Is 
called a "blocked consumer thread.” If the event or data 
Is not immediately available, the processor does not 
simply allow the thread to wait idly while occupying the 
processor. Instead, even though the blocked consumer 
thread is not done with its time quantum, the processor 
puts the blocked thread on a sleep queue and picks 
another thread to execute. This new thread has its own 
preassigned time quantum. Use of a sleep queue allows 
a more efficient use of the processor resources. When 
the awaited event occurs or the awaited data or 
resource becomes available, the processor wakes the 
blocked consumer thread and puts it on the run queue 
to wait for its turn to use the processor. 

[0007] Although the practice of allowing a thread to 
"sleep" while blocked allows a more efficient use of the 
processor, it incurs extra overhead because the proces- 
sor has to take time to pick the next highest thread to 
execute. In addition, this approach can limit the perform- 
ance of certain multi-threaded applications. Assume, for 
example, that a multi-threaded application has two 
threads: thread A and thread B, which share a common 
lock executing in a system with one processor. Thread A 
holds the lock and is waiting on the run queue for the 
processor. Thread B is executing on the processor, but 
requires the lock to continue. The lock is not available 
because thread A is holding it. Thus, thread B is 
blocked, to wait for the lock. When thread B is blocked, 
the processor picks a thread having a highest priority 
from the run queue. 

[0008] Unfortunately, the thread that the processor 
picks may not be thread A. The thread on the run queue 
having the highest priority may not even be for the same 
process as threads A and B. If the processor picks a 
thread from a different process, the processor will have 
to perform an inefficient and costly context switch (to 
execute threads of a new process). When thread A 
finally does run, another context switch will be required 
(to execute threads of the process of threads A and B). 
Even worse, by the time thread A (which has the lock) 
executes, thread B (which needs the lock) may not be a 
highest priority process on the run queue ard may not 
execute right away. This type of scenario demonstrates 
one reason why multi-threaded applications can per- 
form poorly in a shared execution system. 
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SUMMARY OF THE INVENTION 

[0009] A described embodiment of the present inven- 
tion provides a method and apparatus for allowing a 
thread to "share" its time quantum with other threads 
when the thread is blocked. A thread may be blocked, 
for example, if it Is waiting for a resource such as a data 
file or a lock. A thread may also be blocked if it is waiting 
for an event, such as a user keystroke. 

[001 0] A "consumer” thread is defined as a thread that 
needs to consume a resource or to wait for an event. In 
a first embodiment of the present invention, when a 
thread is to be blocked, if there Is another thread waiting 
for execution that is from the same process and that 
"owns" the resource needed by the blocked consumer 
thread, the blocked consumer thread transfers its right 
to execute for its remaining time quantum to the owner 
thread, and the owner thread executes next. This trans- 
fer means that no process context switch is required, 
since the blocked consumer thread and the owner 
thread are threads of the same process. In addition, this 
transfer means that the time before the resource 
becomes available to the blocked consumer thread will 
be short. 

[001 1 ] In another embodiment, the owner thread may 
belong to a different process than the first thread, if the 
two processes are both owned by the same user. In this 
embodiment, the first thread shares its remaining time 
quantum with the second thread, although a context 
switch may be needed. In another embodiment, the 
owner thread may belong to a different process than the 
first thread and the two processes may be owned by dif- 
ferent users. If the system defines the first user as being 
able to share resources with the second user, the first 
thread shares its time remaining time quantum with the 
second thread, although a context switch may be 
needed. 

[0012] In another embodiment of the present inven- 
tion, when a thread is blocked, if the owner thread is 
also blocked, the blocked consumer thread transfers its 
right to execute for its remaining time quantum to 
another thread that is not the owner thread, but that is 
still in the same process. This transfer means that no 
process context switch is required, since the blocked 
consumer thread and the thread to which the remaining 
time quantum is transferred are threads of the same 
process. 

[001 3] In another embodiment, in the case where the 
owner thread is blocked, the thread that is not the owner 
thread may belong to a different process than the first 
thread. If the two processes are both owned by the 
same user. In this case, the blocked thread shares its 
remaining time quantum with the thread that is not the 
owner thread, although a context switch may be 
needed. In another embodiment, the thread that is not 
the owner thread may belong to a different process than 
the first thread and the two processes may be owned by 
different users. If the system defines the first user as 



being able to share resources with the second user, the 
first thread shares its remaining time quantum with the 
second thread, although a context switch may be 
needed. 

5 [0014] Similarly, if a consumer thread is to blocked to 

wait for an event, such as a user keystroke, the remain- 
ing portion of the consumer thread’s time quantum is 
transferred to another thread of the same process that 
is waiting on the run queue for its turn to execute. This 
10 second thread may have a highest priority or may be 
chosen according to any other appropriate criteria. 
Again, this transfer avoids having to perform a context 
switch between processes. 

[0015] In another embodiment, when the blocked 
15 thread is waiting for an event, the blocked thread may 
share its remaining time quantum with another thread, if 
the two processes are both owned by the same user. In 
this case the blocked thread shares its remaining time 
quantum with the second thread, although a context 
20 switch may be needed. In another embodiment, the sec- 
ond thread may belong to a different process than the 
first thread, and the two processes may be owned by 
different users. If the system defines the first user as 
being able to share resources with the second user, the 
25 first thread shares its remaining time quantum with the 
second thread, although a context switch may be 
needed. 

[0016] In accordance with the purpose of the inven- 
tion, as embodied and broadly described herein, the 
30 invention relates to a method of sharing a time quantum 
between threads in a process, comprising the steps, 
performed by the data processing system, of; determin- 
ing that a first thread, which is currently being executed 
by a processor and which has an associated time quan- 
35 turn, is blocked; determining a next thread to be exe- 
cuted by the processor; and transferring unused time in 
the time quantum of the first thread to the next thread to 
be executed. 

[0017] In further accordance with the purpose of the 
40 invention, as embodied and broadly described herein, 
the invention relates to method of sharing a time quan- 
tum between a plurality of threads in a data processing 
system, comprising the steps, performed by the data 
processing system, of; initially assigning a number of 
45 tickets to the plurality of threads; assigning an initial pri- 
ority to a thread of each of the plurality of processes in 
accordance with the number of tickets assigned to the 
threads; and executing the respective threads of the 
plurality of processes in an order Indicated by the tickets 
so assigned to the plurality of threads, so that the propor- 
tion of execution time between any two of the threads is 
the same as the proportion between the number of tick- 
ets of the two processes associated with the threads, 
the execution step including the substeps of; determin- 
55 ing that a first thread, which is currently being executed 
and which has an associated time quantum, is blocked; 
determining a next thread to execute; and transferring 
unused time in the time quantum of the first thread to 
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the next thread to execute. 

[0018] A fuller understanding of the invention will 
become apparent and appreciated by referring to the 
following description and claims taken in conjunction 
with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0019] The accompanying drawings, which are incor- 
porated in and constitute a part of this specification, 
illustrate several embodiments of the invention and. 
together with the description, serve to explain the princi- 
ples of the invention. 

Rg. 1 shows an example of a plurality of multi- 
threaded applications executing on a data process- 
ing system having a single processor, in accord- 
ance with a preferred embodiment of the present 
invention. 

Fig. 2 shows an example of a plurality of multi- 
threaded applications executing on a data process- 
ing system having multiple processors, in accord- 
ance with another preferred embodiment of the 
present invention. 

Rg. 3(a) shows an example of a data structure 
used to implement a embodiment of the present 
invention in a system where multi -threaded applica- 
tions share one processor (such as the system of 
Rg. 1) using a ticket metaphor. 

Fig. 3(b) shows an example of a data structure 
used to implement a preferred embodiment of the 
present Invention in a system where multi-threaded 
applications share more than one processor (such 
as the systems of Fig. 2) using a ticket metaphor. 
Figs. 4(a) and 4(b) are flow charts describing a of 
the present invention in a system where multi- 
threaded applications share at least one processor 
(such as the system of Figs. 1 or 2) using a ticket 
metaphor. 

Fig. 4(c) is a flowchart describing a method per- 
formed when an executing thread is blocked and 
transfers its remaining time quantum to another 
thread. 

Rg. 4(d) is a flow chart describing a method per- 
formed when a thread to which time a was trans- 
ferred completes with time still remaining. 

Rg. 5 shows an example of a data structure used to 
implement a preferred embodiment of the present 
invention In a system where multi -threaded applica- 
tions share more than one processor (such as the 
system of Fig. 2) without implementing the ticket 
metaphor. 

Rg. 6 is a flowchart describing a method performed 
when an executing thread is blocked and transfers 
its remaining execution time to another thread in the 
same process, without implementing the ticket met- 
aphor. 



DETAILED DESCRIPTION OF PREFERRED EMBOD- 
IMENTS 

[0020] Reference will now by made in detail to pre- 
5 ferred embodiments of the invention, examples of which 
are illustrated in the accompanying drawings. Wherever 
convenient the same reference numbers will be used 
throughout the drawings to refer to the same of like 
parts. 

10 

I. Overview 

[0021] The present invention can be implemented on 
a wide variety of data processing systems, including 
15 systems that execute multi -threaded applications and 
that include a single processor or multiple processors. 
Figs. 1-2 show respective examples of each of these 
systems. 

[0022] The present invention can be implemented in 
20 any appropriate data processing system that includes 
multi-threading or similar concepts. Because the inven- 
tion allows a thread that is blocked to share Its unused, 
allotted execution time with other threads, the present 
invention improves the efficiency of execution of threads 
25 in the process and avoids undesirable process context 
switches and delays in executing threads (when the 
threads sharing time quantum are in the same process). 
[0023] Figs. 3 and 4 show an embodiment of the 
present invention that allows sharing of execution rights 
30 among threads using a "ticket" metaphor, as described 
below. Figs. 5 and 6 show an embodiment of the 
present invention that does not use the "ticket" meta- 
phor. Thus, the present invention can be used in a vari- 
ety of operating system environments, and can be used 
35 in contexts that do or do not use a "ticket" metaphor for 
sharing processor resources without departing from the 
spirit and scope of the present invention. 

[0024] Fig. 1 is a block diagram of a data processing 
system 100 having a single processor 102 and a mem- 
40 ory 104. Memory 104 includes one or more multi- 
threaded applications (also called "processes"") 1 10, at 
least one of which contains a plurality of threads 1 12. 
Memory 104 also includes an operating system (OS) 
108, which includes process scheduler software 109. 
45 The steps of the described embodiment of the present 
invention are performed when instructions in process 
scheduler software 1 09 are executed by processor 1 02. 
The present invention allows the threads 112 of each 
multi-threaded application/process 1 1 0 to share proces- 
50 sor 102, as described below. 

[0025] Data processing system 100 (and other data 
processing systems discussed herein) can be, for 
example, a SPARC chip based system, an Ultra server, 
or an Enterprise server (all of which are available from 
55 Sun Microsystems. Inc.). Data processing system 100 
can also be any other appropriate data processing sys- 
tem. 

[0026] Operating system 108 can be, for example, a 
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variation of the Unix operating system that has been 
modified to incorporate the present invention. UNIX is a 
registered trademark in the United States and other 
countries and is exclusively license by X/Open Com- 
pany Ltd. Operating system 108 can be, for example, a 5 
variation of the Solaris operating system, available from 
Sun Microsystems, Inc. that incorporates the functional- 
ity of the present invention. 

[0027] Fig. 1 also includes an input device 150, such 
as a keyboard, mouse, touchpad, touch screen, etc. Fig. 

1 further includes a display device, such as a display 
screen, etc. Fig. 1 further includes a computer readable 
medium 162 and an input device 161 for computer read- 
able medium. Computer readable medium 162 
includes, for example, a floppy disk drive, CD ROM 
reader, or DVD reader, that reads computer instructions 
stored on a computer readable medium, such as a 
floppy disK a CD ROM, or a DVD drive. Fig. 1 also 
includes network connections 105, which can be 
present in at least some implementations of the system 
100. 

[0028] In the following discussion, it will be understood 
that the steps of methods and flow charts discussed 
preferably are performed by processor 102 (or another 
appropriate processor) executing instructions stored in 
memory 104 (or other appropriate memories). It will 
also be understood that the invention is not limited to 
any particular implementation or programming tech- 
nique and that the invention may be implemented using 
any appropriate techniques for implementing the func- 
tionality described herein. The invention is not limited to 
any particular programming language or operating sys- 
tem. 

[0029] The instruction in memory may be read into 
memory from a computer-readable medium. Execution 
of sequences of instructions contained in memory 104 
causes processor 102 to perform the process steps 
described herein. In alternative embodiments, hard- 
wired circuitry may be used in place of or in combination 
with software instructions to implement the Invention. 
Thus, embodiment of the invention are not limited to any 
specific combination of hardware circuitry and software. 
[0030] The term "computer-readable medium" as 
used herein refers to any medium that participates in 
providing instructions to a processor for execution. Such 
a medium may take many forms, including but not lim- 
ited to, non-volatile media, volatile media, and transmis- 
sion media. Non-volatile media includes, for example, 
optical or magnetic disks, such as a storage device. Vol- 
atile media includes dynamic memory. Transmission 
media include coaxial cables, copper wire and fiber 
optics, including the wires that comprise a bus within a 
computer. Transmission media can also take the form of 
acoustic or light waves, such as those generated during 
radio-wave and infra-red data communications. 

[0031] Common forms of computer-readable media 
include, for example a floppy disk, a flexible disk, a hard 
disk, magnetic tape, or any other magnetic medium, a 



CD-ROM, any other optical medium, punchcards, pap- 
ertapes, any other physical medium with patterns of 
holes, a RAM. a PROM, an EPROM, a FLASH-EPROM. 
any other memory chip or cartridge, a carrier wave, or 
any other medium from which a computer can read. 
[0032] Various forms of computer readable media may 
be involved in carrying one or more sequences of one or 
more instructions to a processor for execution. For 
example, the instructions may initially be carried on a 
10 magnetic disk of a remote computer. The remote com- 
puter can load the instructions Into its dynamic memory 
and send the instructions over a telephone line using a 
modem. A modem local to the computer system can 
receive the data on the telephone line and use an infra- 
15 red transmitter to convert the data to an infra-red signal . 
An infra-red detector coupled to a bus can receive the 
data carried in the infra-red signal and place the data on 
the bus. The bus carries data to main memory, from 
which a processor retrieves and executes the instruc- 
20 tions. The instructions received by main memory may 
optionally be stored on a storage device either before or 
after execution by a processor. 

[0033] It will be understood that the present invention 
can also be performed in a distributed data processing 
25 system, where the processor(s) and memory are 
located in different machines. It will also be understood 
that the present invention can also be implemented in a 
distributed system, where the processes, threads, 
arxi/or processors are not all in the same computer. 

30 [0034] A person of ordinary skill in the art will under- 

stand that memory 104 also contains additional infor- 
mation, such as application programs, operating 
systems, data, etc., which are not shown in the figure for 
the sake of clarity. It also will be understood that data 
35 processing system 100 (or any other data processing 
system described herein) can also include numerous 
elements not shown, such as disk drives, keyboards, 
display devices, network connections, additional mem- 
ory, additional CPUs, LANs, input/output lines, etc. 

40 [0035] Fig. 2 is a block diagram of a data processing 

system 200 having multiple processors 102 ’ and a 
memory 104. Memory 104 includes one or more multi- 
threaded applications 110 (also called a "process"), at 
least one of which contains a plurality of threads 112 . 
45 Memory 104 also includes an operating system (OS) 
108, which includes process scheduler software 109. 
The steps of the described embodiment of the present 
invention are performed when instructions in process 
scheduler software 1 09 are executed by one or more of 
so processors 102 ’. The present invention allows the 
threads 1 12 of each multi -threaded application/process 
110 to proportionally share processors 102 ’, as 
described below. 

55 II. Multi-threaded Applications 

[0036] Fig, 3(a) shows an example of a data structure 
used to implement a preferred embodiment of the 
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present invention in a single processor system capable 
of executing multi-threaded applications (such as the 
system of Fig. 1). Fig. 3(b) shows an example of a data 
structure used to implement a preferred embodiment of 
the present invention in a multi -processor system capa- 5 
ble of executing multi -threaded applications (such as 
the system of Fig. 2). Figs. 4(a) and 4(b) are flow charts 
showing steps using the data structures of Figs. 3(a) or 
3(b). 

[0037] In the data structures of Figs. 3(a) and 3(b), 10 

multiple threads in each application/process "share" the 
tickets of their process between them via a ticket data 
structure 305. It should be understood that the systems 
of Fig. 3(a) and 3(b) can also include single-threaded 
applications (not shown), in addition to the multi- 15 
threaded applications. This "ticketing" system Is 
described in more detail in U.S. Application Serial No. 
08/962,140 of Yue, entitled "Method arxl Apparatus for 
Processor Sharing." filed October 31, 1997. 

[0038] While each thread has its own priority 326, the 20 
tickets are held at the process level In fields 340 and 
342 of ticket structure 305. Ticket data structure 305 
also Includes a #slots field 346 and a ticket queue 
pointer 347. The #slots field 346 indicates a number of 
processor slots assigned to each process. In the case of 25 
a single processor system, the number of slots is always 
"1". A multiple processor system can have any number 
of slots less than or equal to the number of processors 
102’. Ticket queue pointer 347 points to a ticket queue 
350, whose function is to hold threads of a process that 30 
are waiting for a processor slot to become available. 
Threads to be executed are taken off ticket queue 350 
and placed on run queue 103 (or 103’) for execution by 
processor(s) 102 (or 102’). 

[0039] Fig. 4(a) Is a flow chart 400 showing steps per- 35 
formed in connection with the multi-threaded applica- 
tions of Figs. 3(a) and 3(b) sharing single processor 102 
or multiple processors 102'. In step 402 of Fig. 4(a), a 
number of tickets and a number of slots are assigned to 
each process. The priority of a thread is assigned based 40 
on the nurrfoer of current tickets in the ticket structure 
305 of its process when the priority is assigned. Thus, 
threads of a same process can have different priorities. 
[0040] When a thread wants to use a processor 102, 

1 02’ (see step 404), it first checks to determine whether 45 
there is an available processor slot (step 406). If there is 
an available slot (i.e., no other thread is waiting in ticket 
queue 350), a priority is determined for the thread in 
step 408. This priority is placed in field 326 of the 
thread's ps_proc_t data structure 304 and the thread is so 
placed in run queue 103 for execution in step 410. Oth- 
erwise (if there are no available processor slots), the 
thread is placed in ticket queue 350 for this process 
(step 412). When a slot becomes available in step 414. 
a thread is taken off ticket queue 350 and its priority 326 ss 
is calculated in step 415 based on the current number of 
tickets held by its process. The thread is then placed in 
run queue 103 for execution in step 416. 



[0041 ] Fig. 4(b) is a flow chart 430 showing st^s for 
executing a thread after the thread is put on the system 
run queue 103 for execution by processor 102. The 
thread is executed for the predetermined time quantum 
specified in the time quantum field 320 in step 434. As 
the thread executes, the "timeleft" field 322 is decre- 
mented for each time unit of execution. Thus, the time 
quantum field is a constant value and the timeleft field is 
regularly decremented as the thread executes. The 
timeleft field 322 holds the amount of execution time 
remaining for the thread during its current chance to use 
the processor. After the thread completes execution, the 
#current tickets 342 for the process of the executing 
thread is reduced by "1" in step 436. If the number of 
tickets held is "0" in step 438, the number of tickets is 
reset to the initial value for the process in step 440 and 
control passes to step 442. Otherwise control passes 
directly to step 442 

[0042] In step 442, if other threads are on the ticket 
queue 350 for this process, the current thread gives up 
its slot in step 444 and is put back on ticket queue 350. 
Its slot is given to the thread at the head of ticket queue 
350 and a new priority Is calculated for this new thread 
based on the number of current tickets 342 for the proc- 
ess in step 446. This new thread (with its newly 
assigned priority) is placed on run queue 103 for execu- 
tion in step 448. 

[0043] If, on the other hand, in step 442 there are no 
threads waiting in the ticket queue 350 when the current 
thread finishes execution, the priority of the current 
thread is recalculated based on the number of current 
tickets for the process in step 490 and the current thread 
is placed back on run queue 103 in step 492 for execu- 
tion. Note that steps 446 and 490 recalculate a priority 
of a thread based on the number of tickets currently held 
by the process to which the thread belongs 
[0044] Because the system of Fig. 3(b) includes mul- 
tiple processors 102', each process is assigned a 
number 346 of "slots" equal, for example, to the number 
of processors in the system. Other implementations of 
the present invention may use other numbers of slots. 
For example, the number of slots could be smaller than 
the number of processors in the system In order to 
reduce the concurrency of execution of processes. In 
the described embodiment, if there are two processors 
in the system, the number of slots would be "2”. Thus, 
for example, if there are only two processors 102' in the 
system and a process has ten threads, only two threads 
of the process at a time can be input to the system run 
queue. The rest of the threads will wait on ticket queue 
350. 

[0045] The previous paragraphs discuss a "ticket" 
metaphor used to apportion execution time among mul- 
tiple threads. It will be understood that other methods 
can be used to apportion execution times among 
threads and that the above-described "ticket" metaphor 
is not necessarily a part of systerr^ implementing the 
present invention. The following paragraphs describe 
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how threads can share their assigned execution time 
quantum. 

[0046] Fig. 4(c) is a f Icwchart 460 describing a method 
performed when an executing consumer thread is 
blocked and transfers its remaining time quantum in 5 
timeleft field 322 to another thread in the same process. 

The "currently executing thread" of step 462 is the 
thread that is blocked. Steps 462 through 472 are per- 
formed when the consumer thread is waiting for a 
resource. Steps 480 through 484 are performed if the io 
consumer thread is waiting for an event. 

[0047] Step 464 determines which of the existing 
threads owns the needed resource using the field 327. 

This thread is called the "owner." In step 466, if the 
owner is on the run queue 103 for this process (i.e., if is 
the owner is not blocked itself) then, in step 468, the 
timeleft 322 of the blocked consumer thread is trans- 
ferred from that thread’s ps__proc_t data structure 304 to 
timeleft field 322 of the ps_j>rocJ data structure of the 
owner thread. This transfer occurs even if the owner 20 
thread does not have the highest priority of the threads 
on the run queue. The owner thread is then started, so 
that it can immediately use the remaining time quantum 
in timeleft field 322 of the blocked consumer thread. 
Because the owner thread is part of the same process 25 
as the consumer thread, no process context switch is 
required. 

[0048] If, on the other hand, in step 470. the owner 
itself is blocked, the remaining time quantum of the 
blocked consumer thread is transferred to the thread at 30 
the head of the same process of the run queue. The 
thread is then started, so that it can immediately use the 
remaining time quantum of the blocked consumer 
thread. Because the newly started thread Is part of the 
same process as the consumer thread, no process con- 35 
text switch is required. This transfer is accomplished, for 
example, by copying the timeleft field 322 from the 
blocked consumer thread second thread. Alternately, 
the timeleft field 322 of the first thread can be added to 
the timeleft field 322 of the second thread. 40 

[0049] Following both steps 468 and 470, the blocked 
consumer thread is placed on the sleep queue 354. The 
thread will be restarted when its resource becomes 
available. An example of this occurrence is shown in 
Fig. 4(d). 45 

[0050] Step 480 determines whether the currently 
executing consumer thread needs to wait for an event 
(as opposed to a blocked resource). If so, in step 482, 
the remaining time quantum in timeleft field 322 of the 
blocked consumer thread is transferred to the ps_proc_t so 
data structure 304 of a thread at the head of the run 
queue 103. This transfer is accomplished, for example, 
by copying the timeleft field 322 from the blocked con- 
sumer thread to the second thread. Alternately, the 
timeleft field 322 of first thread can be added to the time- ss 
left field 322 of the second thread. The thread is then 
started, so that it can immediately use the remaining 
time quantum of the blocked consumer thread. Because 



the newly started thread is part of the same process as 
the consumer thread, no process context switch is 
required. Following step 482, the blocked consumer 
thread is placed on the sleep queue in step 484. The 
thread will be restarted when its event occurs. An exam- 
ple of this occurrence is shown in Fig. 4(d). 

[0051] Fig. 4(d) is a flow chart 490 describing a 
method performed when a thread to which a remaining 
time quantum was transferred completes with time still 
remaining. If, in step 492. a thread completes its execu- 
tion with unused execution time remaining: If, in step 
494, the thread previously borrowed time from a thread 
that is currently blocked; and if. in step 496, the blocked 
consumer thread is waiting for data or an event that is 
available (i.e., data that is not blocked or an event that 
has occurred) then, in step 498, the consumer thread is 
restarted and the remaining time quantum in timeleft 
field 322 is transferred to the newly restarted thread. 
[0052] Fig. 5 shows an example of a data structure 
used to implement an embodiment of the present inven- 
tion in a system where multi-threaded applications 
share more than one processor (such as the systems of 
Fig. 2) but that does not use the ticket metaphor. Note 
that, in contrast to the data structure of Fig. 3, the data 
structure of Fig. 5 does not include a ticket structure 
allowing threads of a single process to share their right 
to execution. In this implementation of the present 
Invention, the data structure of Fig. 5 includes an "active 
queue” 352 for each process. The proc_t structure 301 
of each process points to the active queue 352 for that 
process. Active queue 352 is a list of all threads of the 
process that are currently on the run queue. Thus, the 
thread of the process has the highest priority in the run 
queue will be at the head of the active queue for that 
process. 

[0053] Fig. 6 is a flowchart 660 describing a method 
performed when an executing consumer thread is 
blocked and transfers its remaining execution time to 
another thread in the same process, in a system that 
does not use the ticket metaphor. Fig. 6 is similar to Fig. 
4(c), except that, In steps 670 and 682, the time quan- 
tum in field 322 remaining for the blocked consumer 
thread is transferred to a thread at the head of the active 
queue 352 for the process to which the blocked con- 
sumer thread belongs. This transfer is accomplished, 
for example, by copying the timeleft field 322 from the 
blocked consumer thread to the second thread. Alter- 
nately. the timeleft field 322 of the first thread can be 
added to the timeleft field 322 of the second thread. 
[0054] Thus, in the described embodiment of the 
present invention, when a consumer thread is blocked, 
its remaining execution time is assigned to another 
thread in the same process. This thread can be. for 
example, a thread that controls a resource that is block- 
ing the consumer thread. The thread in the same proc- 
ess can also be a thread in the same process having a 
highest execution priority. Several Implementations of 
the present invention have been discussed herein. A 
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first Implementation Is desorbed In a system where 
threads of a process share "tickets" among themselves. 
A second Implementation Is described In a system 
where each process keeps track of Its threads that are 
waiting to execute using an active queue or an active 
list. In either case, the consumer thread that is blocked 
transfers its unused, allotted execution time to another 
thread In the same process. 

[0055] While the invention has been described In con- 
junction with a specific embodiment. It is evident that 
many alternatives, modifications and variations will be 
apparent to those skilled in the art in light of the forego- 
ing description. For example, threads in the system can 
either have the same time quantum Initially assigned in 
field 320 or can have differing time quanta initially 
assigned in field 320. As another example, when a first 
thread is blocked because a resource owned by another 
thread is not available, Its remaining time quantum can 
be transferred to the owner thread, when the owner 
thread is not in the same process, but Is owned by the 
same user. In this case, the time quantum In timeleft 
field 322 of the first thread (in a first process) would be 
transferred to the second thread (in a second process), 
as described above. Similarly, in another embodiment, a 
blocked thread can share its remaining time quantum 
with an owner thread In a different process that belongs 
to a different user in a predetermined group of users. In 
this case, the remaining time quantum 322 of the first 
thread (belonging to the first user) would be transferred 
to the second thread (belonging to another user in the 
group of users), as described above. 

[0056] As another example, when a first thread Is 
blocked because a resource owned by another thread is 
not available, and when the owner is also not available, 
the remaining time quantum of the first, blocked thread 
can be transferred to a second thread other than the 
owner thread, when the second thread is not in the 
same process, but is owned by the same user. In this 
case, the remaining time quantum 322 of the first thread 
(in a first process) would be transferred to the second 
thread (in a second process), as described above. Sim- 
ilarly, in another embodiment, a blocked thread can 
share its remaining time quantum with a thread other 
than an owner thread owner thread in a different proc- 
ess that belongs to a different user in a predetermined 
group of users. In this case, the remaining time quan- 
tum 322 of the first thread (belonging to the first user) 
would be transferred to the second thread (belonging to 
another user in the group of users), as described above. 
[0057] As another example, when a first thread is 
blocked because it is waiting for an event, its remaining 
time quantum can be transferred to a second thread, 
when the second thread is not in the same process, but 
is owned by the same user. In this case, the remaining 
time quantum 322 of the first thread (in a first process) 
would be transferred to the second thread (in a second 
process), as described above. Similarly, in another 
embodiment, a blocked thread can share its remaining 



time quantum with a second thread in a different proc- 
ess that belongs to a different user in a predetermined 
group of users. In this case, the time remaining quan- 
tum 322 of the first thread (belonging to the first user) 

5 would be transferred to the second thread (belonging to 
another user in the group of users), as described above. 
[0058] Accordingly, it is intended to embrace all such 
alternatives, modifications and variations as fall within 
the spirit and scope of the appended claims and equiv- 

10 alents. 

Claims 

1. A method of sharing a time quantum between 

15 threads, comprising the steps, performed by the 

data processing system, of: 

determining that a first thread, which is cur- 
rently being executed by a processor and 

^0 which has an associated time quantum, is 

blocked; 

determining a next thread to be executed by 
the processor; and 

transferring unused time In the time quantum of 

25 the first thread to the next thread to be exe- 

cuted. 

2. The method of claim 1. wherein the determining 
step includes the step of determining a next thread 

30 to be executed that is from the same process as the 
first thread. 

3. The method of claim 1, wherein the determining 
step includes the step of determining a next thread 

35 to be executed that is from a different process than 
the first thread. 

4. The method of claim 1, wherein the determining 
step includes the step of determining a next thread 

40 to be executed that Is from a different process of a 
different user than the first thread. 

5. The method of claim 1, wherein the transferring 
step includes the step of adding the unused time in 

45 the time quantum of the first thread to a time quan- 
tum of the next thread to execute. 

6. The method of claim 1 , wherein the transferring 
step includes the step of transferring the unused 

so time in the time quantum of the first thread to a time 
quantum of the next thread to execute, in place of 
an original time quantum for the next thread to exe- 
cute. 

55 7. The method of claim 1 . 

wherein the first thread in the determining 
step is being executed by a first processor of a plu- 
rality of processors. 



8 



BNSDOCID: <EP 0913770A2J_> 




15 



EP 0 913 770 A2 



16 



wherein the determining step determines a 
next thread to be executed by the first processor, 
and 

wherein the transferring step transfers 
unused time in the time quantum of the first thread 5 
to the next thread to be executed by the first proces- 
sor. 

8 . A method of sharing a time quantum between a plu- 
rality of threads in a data processing system, com- 
prising the steps, performed by the data processing 
system, of: 

initially assigning a number of tickets to the plu- 
rality of threads; 

assigning an initial priority to a thread of each 
of the plurality of processes in accordance with 
the number of tickets assigned to the threads; 
and 

executing the respective threads of the plurality 
of processes in an order indicated by the tickets 
assigned to the plurality of threads, so that the 
proportion of execution time between any two 
of the threads is the same as the proportion 
between the number of tickets of the two proc- 
esses associated with the threads, the execu- 
tion step including the substeps of: 

determining that a first thread, which is 
currently being executed and which has an 
associated time quantum, is blocked; 
determining a next thread to execute; and 
transferring unused time in the time quan- 
tum of the first thread to the next thread to 
execute. 

9. The method of claim 8 , wherein the data processing 
system includes a plurality of processors, and the 
data processing system has a plurality of processor 
slots; 

wherein the executing step includes the step 
of determining whether there is an available proc- 
essor slot; and 

further including the step of placing a thread 
associated with a one of the plurality of proc- 
esses on a ticket queue of the process, when 
there is no available processor slot, so that the 
thread waits on the ticket queue for an available 
processor slot. 

1 0. The method of claim 8 , wherein the data processing 
system includes a plurality of processors, and the 
data processing system has a plurality of processor 
slots; 

wherein the executing step includes the step 
of determining whether there is an available proc- 
essor slot; and 



further including the step of placing a thread 
associated with a one of the plurality of proc- 
esses onto a processor run queue when there 
is an available processor slot. 

11. The method of claim 10, further including the step 
of calculating a priority of the thread in accordance 
with the number of tickets currently held by the 
thread's process before the thread is placed on the 

10 run queue. 

1 2. The method of claim 1 1 , wherein the executing step 
includes the steps of: 

15 decrementing a number of tickets of a one of 

the plurality of processes whose thread has 
just finished executing for a predetermined time 
period; and 

if the number of tickets for the one process is 

20 equal to zero after the decrementing step, set- 

ting the number of tickets for the one process to 
the initially determined number of tickets for the 
one process. 

25 1 3. The method of claim 1 1 , wherein the executing step 

includes the steps of recalculating the number of 
tickets held by the process; after the thread of the 
process has executed for the predetermined period 
of time. 

30 

14 . The method of claim 1 1 , wherein the executing step 
includes the steps of checking whether there is 
another thread with a higher priority; after the 
thread has finished executing for the predetermined 

35 period of time. 

15. The method of claim 8. wherein at least one of the 
plurality of processes is a multi-threaded applica- 
tion. 

40 

16 . An apparatus to allow sharing a time quantum 
between threads in a process, comprising: 

a portion configured to determine that a first 

45 thread, which is currently being executed by a 

processor and which has an associated time 
quantum, is blocked; 

a portion configured to determine a next thread 
to be executed by the processor; and 

so a portion configured to transfer unused time in 

the time quantum of the first thread to the next 
thread to be executed. 

17. The apparatus of claim 16, wherein the determining 

55 portion includes a portion configured to determine a 

next thread to be executed that is from the same 
process as the first thread. 
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18. The apparatus of claim 16. wherein the determining 
portion includes a portion configured to determine a 
next thread to be executed that is from a different 
process than the first thread. 

5 

1 9. The apparatus of claim 1 6, wherein the transferring 
portion includes a portion configured to add the 
unused time in the time quantum of the first thread 
to a time quantum of the next thread to execute. 

10 

20. The apparatus of claim 16, wherein the transferring 
portion Includes a portion configured to transfer the 
unused time in the time quantum of the first thread 
to a time quantum of the next thread to execute, in 
place of an original time quantum for the next is 
thread to execute. 

21. A computer program product, comprising: 

a computer usable medium having computer 20 
readable code embodied therein for sharing a 
time quantum between threads in a process, 
the computer program product including: 
computer readable program code devices con- 
figured to cause a computer to effect deter min- 25 
ing that a first thread, which is currently being 
executed by a processor and which has an 
associated time quantum, is blocked: 
computer readable program code devices con- 
figured to cause a computer to effect determin- 30 
ing a next thread to be executed by the 
processor; and 

computer readable program code devices con- 
figured to cause a computer to effect transfer- 
ring unused time in the time quantum of the first 35 
thread to the next thread to be executed. 

22. A computer data signal embodied in a carrier wave 
and representing sequences of instructions which, 
when executed by a processor, cause the proces- 40 
sor to share a time quantum between threads in a 
process by performing the steps of: 

determining that a first thread, which is cur- 
rently being executed by a processor and 45 
which has an associated time quantum, is 
blocked: 

determining a next thread to be executed by 
the processor; and 

transferring unused time in the time quantum of so 
the first thread to the next thread to be exe- 
cuted. 
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Fig. 3(a) Multi-threaded Applications (multiple threads 

per process) Sharing a Single Processor 
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Fig. 3(b) Multi-threaded Applications (multiple threads 

per process) Sharing Multiple Processor 








Assign number of tickets to each process based on 
predetermined proportions between processes (i.e., all 
threads of each process will share tickets belonging to 
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Fig. 4(d) 

When a thread completes execution 
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Fig. 3(a) Muiti-threaded Applications (multiple threads 

per process) Sharing a Single Processor 
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Fig, 3(b) Multi^threaded Applications (nriLiltiple threads 

per process) Sharing Muftiple Processor 
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Fig. 4{d) 

When a thread completes execution 




t 



EPO 913 770 A2 




tn 



19 



BNSCXXilD: <EP 0913770A2TI_> 





Curfertty *]fecuttip ^ ^jrr^ritff e^c^/img ttweid 

s4e5wrwPigfl$jicrfgv9iigb»?2-''^^^ r>«8d ta wi^H fer ^n r-<n^ ^ 




BNSDOCID: <EP 0913770A2TI_> 



Time quantum Transfer Between 
Threads 






